Includes smart contracts, libraries, scripts and tests required by automation registry#5
Conversation
| /// Otherwise suspention is postponed until the end of the transition state. | ||
| /// Nothing will be done if automation cycle was already suspended, i.e. in READY state. | ||
| /// If native automation feature is enabled and automation lifecycle has been in READY state, then lifecycle is restarted. | ||
| function onNewCycle() public { |
There was a problem hiding this comment.
On Move Automation side as chain feature flags where applied from epoch to epoch, the feature suspension was done in the expected natural way by implementing and calling on_new_epoch function during chain reconfiguration which was causing epoch-change as well.
With Evm Automation we do not have this option available. So I think feature total suspension should be rather immediate action run by governance.
In that case this function should be updated to be guarded by onlyOwner and also can be named as toggleAutomationFeature(bool enable)
There was a problem hiding this comment.
What would be the use of bool enable argument? We already have functions to enable/disable automation. How this function would be different?
There was a problem hiding this comment.
What is the main reason of having controller and registry separate.
There was a problem hiding this comment.
Ethereum contracts have size limit of 24KB. The idea was to avoid exceeding the size limit by bifurcating the contracts.
…e state -created bash script for deployment and interacting to registry contracts
aregng
force-pushed
the
feature/automation_registry
branch
from
0bcdd7d to
11d5782
Compare
aregng
changed the base branch from
feature/evm_automation
to
feature/blockmeta
variable name fixes
-added priority and task type in parameters -updated test cases
…omationCore updated scripts
aregng
changed the base branch from
feature/blockmeta
to
feature/evm_automation
| function safeFeeRefund( | ||
| uint64 _taskIndex, | ||
| address _taskOwner, | ||
| uint256 _cycleLockedFees, |
There was a problem hiding this comment.
Referring this fix :Entropy-Foundation/aptos-core#329
refund amount can differ from the amount that needs to be unlocked when task is stopped.
Please updated the logic here according to the fix in move-automation.
There was a problem hiding this comment.
I have implemented the same logic as written in move automation. Could you please explain what I'm missing?
-removed access control for external view functions -updated lockedFeeForNextCycle to depositFee
2 participants
This PR includes smart contracts, libraries, scripts and tests required by automation registry related to Entropy-Foundation/smr-moonshot#2523